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AUTHORING ARBITRARY XML DOCUMENTS USING DHTML AND 

XSLT 

5 TECHNICAL FIELD 

This invention relates to authoring extensible markup language (XML) 
documents using dynamic hypertext markup language (DHTML) 

BACKGROUND OF THE I NVENTION 

10 Extensible markup language (XML) is increasingly becoming the preferred 

format for "transferring data. XML is a tag-based hierarchical language that is 
extremely rich in terms of the data that it can be used to represent. For example, 
XML can be used to represent data spanning the spectrum from semi-structured 
data (such as one would find in a word processing document) to generally 

1 5 structured data (such as that which is contained in a table). XML is well-suited for 
many types of communication including business-to-business and client-to-server 
communication. 

Given the breadth of data that can be represented by XML, challenges arise 
when one wishes to provide a user interface to the data that a user can use to 

. 20 manipulate the data or the structure that contains the data. The classical approach 
to the user interface problem, outside of the XML environment, has been to use 
different UI technologies for different types of data (e.g. document, tabular data). 
This approach is clearly not the best when, with XML, it is more likely that a user 
will encounter and wish to interact with data that is both structured and 

25 unstructured. There have been some attempts at solving the problem of enabling a 
user to manipulate'' an XML document, but to date, they are extremely inflexible 
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and do not appreciate the full power behind XML and XSL-T, the latter being a 
transformation that could be used to transform XML into Dynamic HTML or 
DHTML. For more information on XML, XSLT and XSD, the reader is referred 
to the following documents which are the work of, and available from the W3C 
5 (World Wide Web consortium): XML Schema Part 0: Primer, Extensible Markup 
Language (XML) 1.0, XML Schema Part 1: Structures, and XSL Transformations 
(XSLT) Version 1.0. 

Consider, for example, Fig. 1 which illustrates an XML document 100, an 
XSLT transformation (XSL-T) 102, a resultant DHTML document 104, and an 

10 XML schema or XSD file 106. XML document 100 can be represented as a tree- 
like structure where each node of the tree is a corresponding XML tag. The XML 
document 100 must conform to an XML schema that is specified by XSD 106. 
XSL-T 102 is a transformation process that utilizes one or multiple templates to 
transform the XML document tree into a different type of tree — here a DHTML 

15 tree. The DHTML document 104 displays the data that is described in the XML 
tree. XSL-T is simply a collection of templates that enable the data to be 
presented, through DHTML in a way that can be defined by a software developer. 

Consider, for example, an email message that might have several fields, i.e. 
"subject", "to", and the like. Each of these fields might be represented in XML as 

20 tags. For example, the "subject" field might be represented as an XML tag "subj". 
XSL-T creates an engine that attempts to match a current node to various 
templates, selects one, and may find within that template mode nodes to match. 
The XSL-T that transforms the XML representation of the email might include a 
template that matches the "subj" tag. The template would then list the string that 

25 is associated with the "subj" tag, but might place the word "Subject" before the 
string in the DHTML that is ultimately displayed for the user. This is but a very 
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simple example of the transformation process that can take place using XSL-T. 
XSL-T can also be used to add information to the information that is represented 
in an XML document. For example, various headings or other information can be 
added using XSL-T, with the accompanying data underneath the heading coming 
5 from the XML document. Essentially, then, XSL-T provides an extremely robust 
and flexible way of transforming the data that is described by the XML into a 
DHTML presentation. One manifestation of XSL-T is that the resultant DHTML 
structure may bear little resemblance to the corresponding XML tree structure that 
contains the data that is used by the XSLT to provide the DHTML. 

10 The transition from XML to DHTML is then accomplished through XSL-T. 

This is generally a one way transition in which data that is described in XML is 
transformed into a presentation format for the user. Preserving the user experience 
of being able to interact with the data through its presentation format (e.g. 
DHTML) is crucial. While the transformation from XML to DHTML is fairly 

15 straightforward, there has been no clear transformation that would be the inverse 
of this transformation (i.e. transforming DHTML to XML) in a manner that is 
flexible and appreciates the full power of XSL-T. That is, while there are simple 
solutions to this problem, the robust nature of XSL-T and the differences in the 
corresponding XML and DHTML trees make it extremely difficult to attempt 

20 inverse transformation solutions. 

There are solutions that enable a user to enter data in a DHTML document 
which is then copied back to the XML document. These solutions do not, 
however, enable a user to change the sti-ucture of the XML tree that represents the 
data. Additionally, there are solutions that are hardcoded solutions that can enable 

25 some manipulation of the XML tree given a DHTML modification, but the 
hardcoded nature of the solutions make them very specific to the data and XML 
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tags with which they are used. For example, one of the XSL-T templates might 
include a hardcoded solution that allows a user to make structural changes to a 
table, such as adding a new row. This hardcoded solution is then only usable in 
connection with the table for which it was specifically defined. If a developer 
5 wishes to use the hardcoded solution for a different table, they must physically 
alter the programmatic solution to specifically apply to their situation. There are 
solutions which enable authorship of arbitrary XML through user-friendly views, 
but not through DHTML and XSL-T. Exemplary products include Axbortext's 
Adept Editor, SoftQuad's XMetal, INRIA's Thot, and FrameMaker's Framemaker 
10 for SGML. 

Accordingly, this invention arose out of concerns associated with providing 
user interfaces that enable a user to manipulate a DHTML document with the 
manipulations being transferred back to the XML tree that represents the data of 
the DHTML presentation in a flexible, repeatable manner. 

15 

SUMMARY OF THE INVENTION 

Methods and systems of authoring XML using DHTML views are 
described. Various user interfaces can be automatically or semi-automatically 
provided in a DHTML view that enable a user to interact with a DHTML view and 

20 change values (e.g. text or properties) of an associated DHTML tree. Value 
changes are translated to modifications of an associated XML structure. A 
transformation, e.g. an XSL-T, is applied to the modified XML structure which 
then changes the DHTML view to reflect the user's interaction. The interfaces, 
some of which are termed "in document" interfaces, permit a user to interact with 

25 a DHTML view and have value modifications automatically made to a 
corresponding XML document that describes data that is associated with the 
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DHTML view. Presentation of the various "in document" interfaces takes place 
by considering not only an XML schema (of which the XML document is an 
instance), but an XSL-T (XSLT transformation) that was utilized to transform the 
XML document into the DHTML view. 
5 In addition, the notion of a crystal is introduced and is used to map changes 

in a DHTML view directly back to a corresponding XML document. A crystal, in 
a basic form, includes one or more behaviors and associated XSL-T. In the 
illustrated example, a behavior is implemented as binary code that is associated 
with or attached to DHTML tags that are generated by the XSL-T. The crystals are 

10 used to transform XML into the DHTML views. The behaviors of a crystal are 
defined to be data-shape specific or dependent, with the data shape being defined 
by the XML document. The behavior is not necessarily dependent upon any 
schema, data or tags. Because of its data-shape dependent nature, crystals can be 
packaged for reuse with various XML documents which have no relation to one 

1 5 another other than a shape that is defined by the XML. 

Behaviors can be attached to DHTML tags that are generated by the XSL- 
T. The behaviors ensure that user interactions with the DHTML view are mapped 
directly back to the XML document. In this way, the XML document can be 
authored to reflect the changes that are made to the DHTML view by the user. 

20 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a high level block diagram that illustrates an XML document, an 
XSLT transformation, a DHTML view and a XSD or schema. 

Fig. 2 is a high level diagram of a computer system that can be utilized to 
25 implement the described embodiments. 
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Fig. 3 is a flow diagram that describes steps in a method in accordance with 
one described embodiment. 

Fig. 4 is a block diagram that illustrates one aspect of how changes to a 
DHTML view get mapped back to a corresponding XML document. 
5 Fig. 5 is a flow diagram that describes steps in a method in accordance with 

one described embodiment. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
Overview 

Methods and systems of authoring XML using DHTML views are 
10 described. In one implementation, various user interfaces can be automatically or 
semi-automatically provided in a DHTML view that then enable a user to interact 
with a DHTML view and change values (e.g. text or properties) of an associated 
DHTML tree. Value changes are translated to modifications of an associated 
XML structure. A transformation, e.g. an XSL-T, is applied to the modified XML 
15 structure which then changes the DHTML view to reflect the user's interaction. 
The interfaces, some of which are termed "in document" interfaces, permit a user 
to interact with a DHTML view and have those interactions reflected in a 
corresponding XML document that describes data that is associated with the 
DHTML view. These modifications can be made regardless of the complexity of 
20 the XSL-T that was utilized to transform the XML into the DHTML. Presentation 
of the various in document interfaces takes place by considering not only an XML 
schema (of which the XML document is an instance), but an XSL-T (XSLT 
transformation) that was utilized to transform the XML document into the 
DHTML view. 

25 In another implementation, the notion of a crystal is introduced. A crystal, 

in a basic form, includes one or more behaviors and associated XSL-T. The 
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crystals are used to transform XML into the DHTML views. The behaviors of a 
crystal are defined to be data-shape specific or dependent, with the data shape 
being defined by the XML document. The behavior is not necessarily dependent 
upon any schema, data or tags. Because of its data-shape dependent nature, 
5 crystals can be packaged for reuse with various XML documents which have no 
relation to one another other than a shape that is defined by the XML. In the 
described implementation, behaviors are attached to the DHTML tags that are 
generated by the XSL-T. The behaviors ensure that user interactions with the 
DHTML view are mapped directly back to the XML document. In this way, the 
10 XML document can be authored to reflect the changes that are made to the 
DHTML view by the user. Because crystals are data shape-dependent and not 
schema dependent, as the shape is defined by the XML document, they can be 
used for authoring fragments of XML belonging to different schemas; those 
fragments simply share the same shape. 

15 

In this document, the following terminology will be used: 

• Schema - a file (e.g. an XSD file) describing the schema for a particular 
type of XML document; schemas typically contain predefined tags and 

20 attributes that define the shape of the XML trees that represent an XML 

document; the schema provides a structure that each XML document must 
comply with; while editing an XML document, the schema is accessible 
through an instantiated DOM (document object model) (XDR DOM). 
Alternately, relevant information can be obtained from the schema and 

25 cached for use. 

• XML document - an instance of an XML schema. Theoretically, for one 
schema there could be an infinite number of documents that instantiate the 
schema. When editing a document, the initial version and the final version 

30 of the document both adhere to the same schema, though the documents 

themselves are different. While processing, the XML document is 
instantiated through an instantiated DOM (XML DOM). 
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• XSLT transformation ~ an XML file that transforms the XML document 
into an HTML view; for each XML document there could be any number 
of XSLT transformations, each creating a different HTML view over the 
same document. An XSL-T file consists of one or more templates that 

5 match elements in the XML document. The XSL-T file that is initially 

authored by the application author is transformed by NetDocs when applied 
in edit mode into a NetDocs editing aware XSL-T. This transformation may 
break out templates into multiple templates, and add the appropriate 
behaviors (see below) based on NetDocs-specific hints added by the 
10 application developer. While editing the XML document, the transformed 

XSL-T is accessible to NetDocs through an instantiated DOM (XSL-T 
DOM). 

• DHTML view — this is the result of the XSLT transformation applied on 
the XML document. The DHTML tree contains visual cues for displaying 
the data, but also behaviors. These behaviors are introduced by the XSLT 
transformation. While there could be behaviors introduced by the author of 
the XSLT transformation, there are behaviors introduced by NetDocs when 
it applies the transformation. These latter behaviors hold the logic for: 

o Copying to the XML DOM the values of the HTML leaf nodes that 
are modified 

o Determining, based on the cursor location in the HTML document, 
what editing services are available in the editing context. The 
editing context is determined by the HTML context in conjunction 
with the XSD context and the XSL-T template that was applied to 
generate that part of the view. The service is made known to the 
user 

■ In-place (in the editing area) for pre-defined UI structures 
(e.g. table, grid, calendar control, label) 

■ Enabling the appropriate XML editing context blocks in the 
NetDocs ContextBlock area. 

o Modifying the structure of the XML DOM based on the editing 
service selected 

o Incrementally updating the HTML view, by refreshing just the part 
of the view that is affected by the changes to the XML DOM. 



Exemplary Computing Environment 

The embodiment described just below can be employed in connection with 
various computer systems, A computer system, for purposes of this document, can 
40 be considered as any computing device that includes some type of processor, i.e. a 
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microprocessor, and some type of operating system. Thus, a computer system can 
be construed to include, without limitation, traditional desktop computers, more 
powerful servers, various hand-held devices such as cell phones, pocket-held 
computer devices and the like. 
5 Fig. 2 shows an exemplary computer system that can be used to implement 

the embodiments described herein. Computer 130 includes one or more 
processors or processing units 132, a system memory 134, and a bus 136 that 
couples various system components including the system memory 134 to 
processors 132. The bus 136 represents one or more of any of several types of bus 

10 structures, including a memory bus or memory controller, a peripheral bus, an 
accelerated graphics port, and a processor or local bus using any of a variety of 
bus architectures. The system memory 134 includes read only memory (ROM) 
138 and random access memory (RAM) 140. A basic input/output system (BIOS) 
142, containing the basic routines that help to transfer information between 

15 elements within computer 130, such as during start-up, is stored in ROM 138. 

Computer 130 further includes a hard disk drive 144 for reading from and 
writing to a hard disk (not shown), a magnetic disk drive 146 for reading from and 
writing to a removable magnetic disk 148, and an optical disk drive 150 for 
reading from or writing to a removable optical disk 152 such as a CD ROM or 

20 other optical media. The hard disk drive 144, magnetic disk drive 146, and optical 
disk drive 150 are connected to the bus 136 by an SCSI interface 154 or some 
other appropriate interface. The drives and their associated computer-readable 
media provide nonvolatile storage of computer-readable instructions, data 
structures, program modules and other data for computer 130. Although the 

25 exemplary environment described herein employs a hard disk, a removable 
magnetic disk 148 and a removable optical disk 152, it should be appreciated by 
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those skilled in the art that other types of computer-readable media which can 
store data that is accessible by a cpmputer, such as magnetic cassettes, flash 
memory cards, digital video disks, random access memories (RAMs), read only 
memories (ROMs), and the like, may also be used in the exemplary operating 
5 environment. 

A number of program modules may be stored on the hard disk 144, 
magnetic disk 148, optical disk 152, ROM 138, or RAM 140, including an 
operating system 158, one or more application programs 160, other program 
modules 162, and program data 164. A user may enter commands and information 

10 into computer 130 through input devices such as a keyboard 166 and a pointing 
device 1 68. Other input devices (not shown) may include a microphone, joystick, 
game pad, satellite dish, scanner, or the like. These and other input devices are 
connected to the processing unit 132 through an interface 170 that is coupled to 
the bus 136. A monitor 172 or other type of display device is also connected to the 

15 bus 136 via an interface, such as a video adapter 174, In addition to the monitor, 
personal computers typically include other peripheral output devices (not shown) 
such as speakers and printers. 

Computer 130 commonly operates in a networked environment using 
logical connections to one or more remote computers, such as a remote computer 

20 176. The remote computer 176 may be another personal computer, a server, a 
router, a network PC, a peer device or other common network node, and typically 
includes many or all of the elements described above relative to computer 130, 
although only a memory storage device 178 has been illustrated in Fig. 2. The 
logical connections depicted in Fig. 2 include a local area network (LAN) 180 and 

25 a wide area network (WAN) 182. Such networking environments are 
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commonplace in offices, enterprise-wide computer networks, intranets, and the 
Internet. 

When used in a LAN networking environment, computer 130 is connected 
to the local network 180 through a network interface or adapter 184. When used 
5 in a WAN networking environment, computer 130 typically includes a modem 1 86 
or other means for establishing communications over the wide area network 1 82, 
such as the Internet. The modem 186, which may be internal or external, is 
connected to the bus 136 via a serial port interface 156. In a networked 
environment, program modules depicted relative to the personal computer 130, or 

10 portions thereof, may be stored in the remote memory storage device. It will be 
appreciated that the network connections shown are exemplary and other means of 
establishing a communications link between the computers may be used. 

Generally, the data processors of computer 130 are programmed by means 
of instructions stored at different times in the various computer-readable storage 

15 media of the computer. Programs and operating systems are typically distributed, 
for example, on floppy disks or CD-ROMs. From there, they are installed or 
loaded into the secondary memory of a computer. At execution, they are loaded at 
least partially into the computer's primary electronic memory. The invention 
described herein includes these and other various types of computer-readable 

20 storage media when such media contain instructions or programs for implementing 
the steps described below in conjunction with a microprocessor or other data 
processor. The invention also includes the computer itself when programmed 
according to the methods and techniques described below. 

For purposes of illustration, programs and other executable program 

25 components such as the operating system are illustrated herein as discrete blocks, 
although it is recognized that such programs and components reside at various 
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times in different storage components of the computer, and are executed by the 
data processor(s) of the computer. 

Exemplary Implementation 

5 The inventive methods and systems discussed below are configured for use 

in connection with an implementation, aspects of which are described in the 
documents incorporated by reference above. That implementation essentially 
provides a single application program having a single navigable window that can 
be navigated to multiple different functionalities that are provided by the 
10 application program. The functionalities are extensible and can be extended via a 
network such as the Internet. 

Use of Schema and XSL-T to Generate a User Interface 
When a user interacts with a DHTML document for the purpose of 
15 changing, in some way the document through either manipulation of one or more 
of its values or properties, it is important that those manipulations be made, in a 
consistent manner, to the XML document that describes the structure of the data 
behind the DHTML document. In order to manipulate the XML document that 
describes the structure of the data behind the DHTML, there needs to be a way to 
20 transform user interactions in the DHTML to changes in the XML document. This 
is the problem of finding an inverse of the transformation function that is provided 
by the XSL-T. 

In one implementation, the described embodiment addresses this problem 
by automatically (or semi-automatically, with some hint given by the application 
25 developer) generating an appropriate user interface (UI) within the DHTML 
document that allows the user to manipulate or interact with the DHTML 



WO 01/98927 



PCT/US01/15576 



13 

document. The presentation of the UI takes into account not only the XML 
schema, but also the XSL-T transformations that were utilized to provide the 
DHTML. This represents a significant departure from other XML authoring 
solutions that look only to the XML schema to determine what can and cannot be 
5 added to an XML document. The UIs thus allow user interaction with the 
DHTML view (e.g. adding and/or deleting structure) to be directly transferred 
back to the XML document. 

There are many various potential types of UIs that can be presented to a 
user to enable them to interact with a document. Some examples include, without 

10 limitation, context blocks which are automatically added to a window based upon 
the user's context. Context blocks are discussed in more detail in the Application 
entitled "Task Sensitive Methods And Systems For Displaying Command Sets", 
incorporated by reference above. Other forms of UIs can include so-called 
widgets which are decorations within a document itself that allow a user to interact 

15 with the document. For example, if a document contains a table, there can be 
additional adornments around the table on which a user can click to add or delete a 
row or column, or to move items around within the column. Another type of UI is 
an accelerator which allows interaction through the keyboard. For example, if you 
press "Control-L" some type of predefined action is implemented. 

20 In this described embodiment, a decision process is undertaken that decides 

which UIs to present to a user and when to present them. That is, there are 
potentially a number of different UI choices that can be made depending on what a 
user is doing in a particular document and where they are in the document. An 
inventive approach is to utilize a number of different parameters and based upon 

25 analysis of the parameters make a decision on which UI to present to a user so that 
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they can interact with the DHTML view. In the described embodiment, the 
following parameters can be used: 

• Selection of where a user is in a particular DHTML document. This 
5 translates to where a user is in a particular XML document because 

the selection initially starts on the DHTML side and has a 
correspondence on the XML side; 

• The portion of the XML schema that corresponds to the user's 
selection; 

10 • The UI types that would be desirable to generate; and 

• The XSL-T file 

In the XSL-T file, there are certain constructs that can be suggestive of 
certain structures in the resultant DHTML. For example, the XSL-T file may 
include a "xsl:for-each" construct (i.e. for each customer, take a certain action). 
15 This construct is suggestive of a repetitive structure in the DHTML, such as a 
table or a paragraph. That is, if there are a number of customers, then repeating a 
certain action would repetitively define a certain type of structure. By considering 
these XSL-T constructs, certain UI types can be identified that can be displayed 
for the user. 

20 An example is table editing. For example, if expenses are optional, 

according to the schema, initially there may be no expenses in a table. The XSL-T 
would have a "for-each" construct to render each expense, but since there are none 
in the XML doc, nothing is displayed. The UI should in this case produce a 
context block for adding an expense. 

25 Once the first expense is created, by re-applying the XSLT transformation, 

a table is now viewable. At this point, based on the XSL-T hint that there is a 
"for-each" associated with an expense, and the schema information that multiple 
expenses can be added, a decision is made to not show the "Add expense" as a 
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context block, but to add an appropriate in-doc UI that would now take over the 
functionality of adding additional expenses as new rows to the table. 

When addressing the problem of which UI to display for the user to enable 
interaction with a document, it is desirable to keep the overall appearance that is 
5 presented to the user as uncluttered as possible. For example, many different 
context blocks could be presented to user, each with its own engagable buttons 
that can be engaged by a user for interacting with the DHTML view. This is not 
desirable though because it can potentially clutter the context block area. It would 
be more ideal to have "in document" UIs (e.g. widget UIs) within a document that 

10 are specific to the document itself and which allow a user to interact with the 
document. An "in document" UI is a UI that appears within a portion of the 
document and enables user interaction with a portion of the document. Consider, 
for example, a Word document that contains an embedded drawing. When the 
user clicks on the embedded drawing, the drawing can appear within a frame that 

15 contains one or more buttons that can be clicked on to manipulate the drawing, 
e.g. a rotate button to rotate the drawing. The buttons that are associated with the 
embedded drawing are considered as "in document" UIs. 

In order to provide these types of UIs, the described embodiment examines 
the XSL-T file to identify which UI candidates are more suited to have their 

20 functionalities provided by "in document" UIs. 

For example, if the schema specifies that multiple expenses are allowed, 
and the XSL-T has a "for-each" construct for expenses, by looking at the first 
element introduced by the XSL-T after an expense is matched, it could determine 
what kind of helpful UI to add. If an DHTML TABLE is created, then it should be 

25 adorned' with table-editing widgets, but if there is SPAN, for example, then create 
a context block, and not an in-doc UI. 
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That is, the above-described context blocks are not "in document" because 
they are provided within a pane that is disposed adjacent a document area within 
which a user can work on a document. One goal of the described embodiment is 
to identify UIs, based upon the analysis discussed below, that are the best 
5 candidates for incorporation as "in document" UIs that specifically adorn 
document portions and permit user interaction with the document itself. 

Consider that, without taking into account the XSL-T in the analysis of 
which UIs to present to a user, the only UIs that could be presented would not be 
in-document UIs. The context blocks are the most generic UI constructs in the 

10 present example. But if we know that we have a table created in DHTML, then 
the context blocks can be replaced by in-doc constructs. By inspecting the XSL-T 
we can find out what DHTML construct is created by the XSLT transformation. 
That is, without consideration of the XSL-T, only generic UIs, e.g. the context 
block UIs, would likely be generated. For example, if a user is working within a 

15 DHTML document that contains a table, a context block can be provided that 
enables the user, through manipulation of various "out of document" UIs to 
manipulate the table, e.g. adding a row, column and the like. By considering the 
XSL-T, the UI that is produced can be refined and the context blocks, or at least a 
portion of the functionality that is provided by the context blocks, can be replaced 

20 with other types of in document UIs . The XSL-T is thus used for refinement of 
the UIs, 

Fig. 3 shows a flow diagram that describes steps in a UI generation method 
in accordance with this described embodiment. Step 300 makes a selection in a 
DHTML document. This step is implemented by a user moving their cursor to a 
25 particular area within a document. Step 302 determines, based upon the user's 
selection, the corresponding selection in the XML document. For example, if a 
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user has selected a particular portion of a table used to display a specific fragment 
of the XML document, then this step determines the exact fragment of the XML 
document that corresponds to the user's selection. Based on the selection in the 
XML document, step 304 determines the appropriate place in the XML schema 
5 that corresponds to the selection and the various types of actions that can be taken 
from this selection. The various types of actions correspond to the various ways in 
which a user might manipulate the portion of the document that they have 
selected. Step 306 then produces the appropriate operations that can be 
undertaken for the various action types. For example, if the user is working in a 

10 table, this step might produce operations for adding a row or column or deleting a 
row or column. Once the operations are produced by step 306, step 308 
determines, from the XSL-T file, what type of UI to display for the user If the 
XSL-T is not considered in this process, then the available UIs would be presented 
as context blocks (i.e. not "in document" UIs). By using the XSL-T, the described 

15 embodiment refines the production of context blocks by reducing the number of 
context blocks that are produced and, instead, producing "in document" UIs that 
now relocate the functionality that would otherwise be provided by the context 
blocks. 
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Manipulation of XML Structures Using Crystals 

Recall that one of the benefits of XML is the richness with which data can 
be described. XML, by its very nature, can provide a wide variety of variations of 
data. Because of this, UI solutions for interacting with data (displayed in DHTML 
5 using XSL-T) have been hardcoded and specific to individual schemas. This is a 
manifestation of the ease with which hardcoded solutions can be provided through 
XSL-T. 

In one described embodiment, the notion of a crystal is introduced to enable 
interactions with a DHTML view to be directly mapped back to the XML file or 

10 tree. Advantageously, the crystals are configured to work on various data shapes, 
independent of the XML schemas. TMs means that when the data has a particular 
shape, as defined by the XML tree that contains the data, specific crystals that are 
configured for that particular shape can be used to render the DHTML and also 
ensure that user interactions with the DHTML view are directly mapped back to 

15 the XML tree. The crystals do not care about the specific data that is provided by 
the data shape, nor the schema or tags that are used to contain the data. 

Consider, for example, Fig. 4 which shows an XML document 400, a 
crystal 402 and the resultant DHTML document 404. In one basic form, a crystal 
comprises one or more behaviors 406 and the basic XSL-T 408 that is utilized to 

20 transform the XML into the DHTML. The behaviors are implemented, in this 
particular example, as binary code that is associated with or attached to the 
DHTML tags that are generated by the XSL-T. Consider, for example, the 
hierarchical tree that is shown directly below XML document 400. This 
hierarchical tree represents a portion of an XML tree that is maintained in memory. 

25 In this example, the tree has a "products" root node and a "product 1" node that is 
a child of the "products" root node. Underneath the "product 1" node are three 



WO 01/98927 



PCT/US01/15576 



19 

children nodes labeled "name", "quantity", and "price". This XML tree may thus 
represent a portion of a purchase order that is utilized to purchase various 
products. When rendered by the crystal 402, the resulting DHTML view is shown 
at 410. This DHTML view is diagrammed directly above view 410 as a tree with a 
5 behavior associated with a DHTML tag. The DHTML view is essentially a table 
that contains data that is provided by the XML document. Assume now that a user 
wishes to modify the purchase order by adding an additional product with a 
corresponding quantity and price. In the past, the solution to this problem might 
be to hardcode a function that added a specific "product tag" to the XML and then, 

10 correspondingly, to the DHTML view. This is a very inflexible solution that is tied 
specifically to the schema and tags of the XML document. In the described 
example, modification of the XML document takes place via the behavior or 
behaviors that are associated with the crystal 402. Specifically, the behavior that is 
defined for this particular XML tree structure includes the modifications that can 

15 be made to the XML document and a mapping that maps the changes to the 
DHTML view using application of XSL-T. This behavior is data shape-dependent 
and not schema- or data-dependent. 

This is diagrammatically illustrated in Fig. 4 by the DHTML tree structure 
shown underneath the DHTML view 404. There, a node corresponding to the 

20 "product" node is shown adorned with a behavior. This behavior is binary code 
that enables a user to interact, via an appropriate UI (such as an in document "add 
product" button 411 attached to the table) with the DHTML view and have any 
defined modifications made by the user mapped back to the appropriate XML tree. 
When a user interacts with the DHTML view, the XML tree is structurally 

25 manipulated (as by adding the appropriate tags and structure), and then the XSL-T 
is invoked to redisplay the DHTML view. 
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In the purchase order example, assume that the user adds a new product to 
the DHTML view table by clicking on "add product" button 411 which adds a new 
row to table 410. In this example, when the new product is added, the behavior or 
binary code maps the modification back to the XML tree and incorporates the 
5 modification by making a structural change to the XML tree. In this specific 
example, the structural change would include adding a branch to the XML tree to 
represent the newly-added product. This added branch is shown as the dashed 
branch on the "Products" XML tree. 

Consider the second XML tree 412 shown directly below the Products 

10 XML tree. That tree is an "Addresses" XML tree and is associated with addresses 
that might appear in an address book. This data is extremely different from the 
data that is associated with the Products XML tree. In fact, there is no relation at 
all between the data. Notice, however, that the Addresses XML tree has the same 
shape as the XML tree appearing directly above it. In the described embodiment, 

15 a similar crystal can be used to render a DHTML address book that contains 
entries for a name, street and zip code. The crystal would likely contain slightly 
different XSL-T for labeling purposes, but can contain the same exact behavior 
that was utilized in the above example to manipulate the structure of the Products 
XML tree. To this extent, a user interface button 411 is provided on the Address 

20 table and includes the same behavior as the user interface button associated with 
the Products table. Thus, when a user adds an entry to their address book, the 
behavior, or binary code, that is associated with the DHTML "Address" tag would 
ensure that any changes made to the DHTML view are mapped directly back to the 
corresponding XML document. 

25 The crystals can advantageously be prepackaged software containers that 

include the behaviors that are specific to the shape of the data and not necessarily 
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dependent upon the schema or specific data that may be contained by an XML 
document. This approach is very well suited to handling complex XSLT 
transformations which naturally flow from the robustness that XSL-T provides. 
By incorporating and associating behaviors in the DHTML tree, problems 
5 associated with handling complex XSLT transformations insofar as XML 
authoring is concerned are solved. This approach is extremely flexible and is not 
tied to any one schema or specific data, as were the solutions in the past. This 
approach also provides the application developer with the ability to develop 
complex XSL-T, without worrying about how the underlying XML is going to be 

10 manipulated responsive to a user manipulating the DHTML document. Further, 
because the approach utilizes crystals having behaviors that are specific to data 
shape and not specific to schema or data, the crystals are reusable across any XML 
documents that have shapes that correspond to the shapes for which the various 
crystals were designed. 

1 5 Fig. 5 is a flow diagram that shows steps in a method in accordance with 

the embodiment described above. Step 500 defines multiple crystals each of 
which include one or more behaviors. In the described example, behaviors are 
implemented as binary code. The behaviors are specific to a data shape and do not 
depend on a schema or specific data. Step 502 uses one or more of the crystals to 

20 render a DHTML view from an XML document. Step 504 attaches at least one 
behavior to a DHTML tag. The behavior ensures that any modifications that are 
made to the DHTML view are mapped back to and appropriately change the XML 
document that contains the data in the DHTML view. Step 506 interacts with the 
DHTML view in some way, based upon user input via a UL This step can be 

25 implemented by a user interacting with some type of structure, for example a table, 
within the DHTML view. Responsive to the user interaction with the DHTML 
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view, step 508 uses the behavior to map the user's interaction back to the XML 
document and make the appropriate structural changes in the XML tree that 
contains the data. For example, the XML branch in Fig. 4 off of the "Products" 
node, indicated with a dashed line, might be the result of a user who adds a new 
5 product to the purchase order provided in the DHTML view. 

Example 

The above approach is very flexible and can be conveniently used by 
application developers to provide applications. Assume that an independent 

10 software vendor (ISV) develops applications for end users and he wants to 
construct a purchase order. The ISV can select an appropriate XML schema for 
the purchase order which would then define the types of tags that the purchase 
order can contain. The ISV would need to write the appropriate XSL-T that could 
present the purchase order in DHTML in a ISV-defined manner. Perhaps the ISV 

15 wants to make the purchase order specific to a particular company. The XSL-T 
provides a way for the ISV to do this. That is, each ISV may wish to present their 
data differently in a way that is specific to the ISV. Thus, while they each may use 
the same schema, there will be many different instances of the schema each of 
which can be potentially very different from the others. One goal of the crystal- 

20 based implementation discussed above, is that it should be very easy for ISVs to 
develop applications based on XML. Accordingly, when the ISV writes their 
XSL-T, they can incorporate various behaviors that are provided by multiple 
different crystals. These crystals are predefined so that the ISV need not worry 
about defining them. They can simply select the crystals that are appropriate for 

25 their shape of data, and incorporate them with XSL-T. Now, when the XML is 



WO 01/98927 



PCT/US01/15576 



23 

transformed into DHTML, user interactions with the DHTML view can be 
mapped to the underlying XML document. 

Although the invention has been described in language specific to structural 
features and/or methodological steps, it is to be understood that the invention 
5 defined in the appended claims is not necessarily limited to the specific features or 
steps described. Rather, the specific features and steps are disclosed as preferred 
forms of implementing the claimed invention. 
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CLAIMS 

1. A method of providing a user interface (UI) comprising: 
rendering a DHTML document from an XML document using at least one 

XSLT transformation (XSL-T); and 
5 presenting a user interface based, at least in part, on the XSL-T that was 

used to render the DHTML document. 

2. The method of claim 1, wherein said presenting comprises 
automatically presenting the user interface. 

10 

3. The method of claim 1, wherein the user interface comprises a 
context block. 

4. The method of claim 1, wherein the user interface comprises an in- 
1 5 document user interface. 

5. The method of claim 1, wherein the user interface comprises an 
accelerator. 

20 6. The method of claim 1, wherein the user interface comprises one or 

more of the following: a context block, an in-document user interface, and an 
accelerator. 

7. The method of claim 1, wherein the presenting comprises deciding 
25 which user interface to present from a number of user interfaces. 



WO 01/98927 



PCT/US01/15576 



25 

8. The method of claim 7, wherein deciding comprises: 

ascertaining a user's actions within a document; and 

presenting a user interface based on the ascertained user's actions. 

5 9. One or more computer-readable media having computer-readable 

instructions thereon which, when executed by a computer, implement the method 
of claim 1. 

10. A method of providing a user interface comprising: 
10 considering multiple parameters one of which includes an XSL-T file; and 

based upon the considered parameters, rendering a user interface sufficient 
to enable a user to interact with a DHTML view that has been rendered by the 
XSL-T file from an XML document. 

15 11, The method of claim 10, wherein one parameter comprises a user 

location within a particular document. 

12. The method of claim 10, wherein one parameter comprises a portion 
of an XML schema that corresponds to a user's selection. 

20 

13. The method of claim 10, wherein one parameter comprises one or 
more UI types that would be desirable to generate. 

14. The method of claim 10, wherein the parameters comprise: 
25 a user location within a particular document; 

a portion of an XML schema that corresponds to a user's selection; and 
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one or more UI types that would be desirable to generate. 

15. The method of claim 10, wherein the considering of the multiple 
parameters comprises considering one or more constructs within an XSL-T file. 

16. The method of claim 10, wherein the considering of the multiple 
parameters comprises identifying from multiple user interfaces which user 
interfaces are more suited to have their functionalities provided by an in-document 
user interface. 

17. The method of claim 10 further comprising modifying structure of 
the XML document based upon the user engaging the user interface. 



18. The method of claim 10, wherein the user interface comprises an in- 
1 5 document user interface. 



20 



19. One or more computer-readable media having computer-readable 
instructions thereon which, when executed by a computer, implement the method 
of claim 10. 



20. A method of providing a user interface comprising: 
making a selection in a DHTML view; 

determining, based upon the selection, a corresponding selection in an 
XML document; 

25 determining, based upon the corresponding selection in the XML 

document, a corresponding portion of an XML schema; 
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determining, based upon the XML schema portion, one or more types of 
action that can be undertaken; 

producing one or more operations that can be undertaken for various 
determined action types; and 
5 determining, from an XSL-T file that rendered the DHTML view, a user 

interface type that can be displayed for a user and used to implement the one or 
more operations. 

21. The method of claim 20, wherein the making of the selection 
10 comprises moving a cursor to a particular area within a document. 

22. The method of claim 20, wherein the action types correspond to 
ways in which a user might manipulate a portion of a document they have 
selected. 

15 

23. The method of claim 20, wherein the user interfaces comprise in 
document user interfaces. 

24. The method of claim 20 further comprising displaying an in- 
20 document user interface of a determined interface type for the user. 

25. The method of claim 24 further comprising manipulating structure 
of the XML document based upon user input through the displayed user interface. 
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26. One or more computer-readable media having computer-readable 
instructions thereon which, when executed by a computer, implement the method 
of claim 20. 

5 27. A method of manipulating an XML document comprising: 

defining one or more crystals, each of which containing one or more 
behaviors and an XSLT transformation for transforming an XML document into a 
DHTML view; 

using the one or more crystals to render a DHTML view from an XML 
1 0 document; 

enabling user interaction with the DHTML view; and 

mapping, via the one or more behaviors, user interactions in the DHTML 
view to the XML document. 

15 28. The method of claim 27, wherein the one or more behaviors are 

data-shape dependent. 

29. The method of claim 27, wherein the one or more behaviors are 
data-shape dependent on a data shape defined by the XML document. 

20 

30. The method of claim 27, wherein the one or more behaviors are 
configured to function independently of an XML schema of which the XML 
document is an instance. 
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31. The method of claim 27, wherein the one or more hehaviors are 
configured to function independently of XML tags that might be used. 

32. The method of claim 27, wherein the behaviors are implemented as 
5 binary code. 

33. The method of claim 27, wherein the crystals are reusable across 
different XML documents. 

10 34. One or more computer-readable media having computer-readable 

instructions thereon which, when executed by a computer, implement the method 
of claim 27. 

35. One or more computer-readable media having computer-readable 
1 5 instructions thereon which, when executed by a computer, cause the computer to: 

provide multiple crystals, each of which containing one or more behaviors 
and an XSLT transformation for transforming an XML document into a DHTML 
view; 

use one or more of the crystals to render a DHTML view from an XML 
20 document; 

attach at least one behavior to at least one DHTML tag; 
ascertain that a user has interacted with a DHTML view associated with the 
at least one DHTML tag; and 

use the behavior associated with the at least one DHTML tag to map a user 
25 interaction back to the XML document and make associated structural changes in 
the XML document. 



WO 01/98927 



PCT/US01/15576 



30 

36. The one or more computer-readable media of claim 35, wherein the 
behaviors are implemented as binary code. 

5 37. The one or more computer-readable media of claim 35, wherein the 

behaviors are data shape dependent. 

38. The one or more computer-readable media of claim 35, wherein the 
behaviors are not dependent upon an XML schema. 

10 

39. A method of manipulating an XML document comprising: 
associating one or more behaviors with a DHTML tag in a DHTML view 

that has been rendered from an XML document; and 

responsive to a user interacting with a DHTML view associated with the 
15 DHTML tag, using the one or more behaviors to map user interactions to the XML 
document and effect structural changes on the XML document. 

40. The method of claim 39, wherein the one or more behaviors are data 
shape-dependent. 

20 

41. The method of claim 39, wherein the one or more behaviors are data 
shape-dependent, the data shape being defined by the XML document. 

42. The method of claim 39, wherein the one or more behaviors are 
25 independent of any XML schema. 
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43. The method of claim 39, wherein the one or more behaviors are 
independent of data values. 

44. The method of claim 39, wherein the one or more behaviors are 
5 independent of one or more of: (a) any XML schema and (b) data values. 

45. A software structure embodied on a computer-readable medium 
comprising one or more crystals, each of which containing at least one behavior 
and XSL-T for rendering XML into DHTML, the behaviors being data shape 

10 dependent and being configured for use with common data shapes independent of 
any XML schema. 
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